Programmable logic devices (“PLDs”) are a well-known type of integrated circuit that can be programmed to perform specified logic functions. One type of PLD, the field programmable gate array (“FPGA”), typically includes an array of programmable tiles. These programmable tiles can include, for example, input/output blocks (“IOBs”), configurable logic blocks (“CLBs”), dedicated random access memory blocks (“BRAMs”), multipliers, digital signal processing blocks (“DSPs”), processors, clock managers, delay lock loops (“DLLs”), and so forth. As used herein, “include” and “including” mean including without limitation.
Each programmable tile typically includes both programmable interconnect and programmable logic. The programmable interconnect typically includes a large number of interconnect lines of varying lengths interconnected by programmable interconnect points (“PIPs”). The programmable logic implements the logic of a user design using programmable elements that can include, for example, function generators, registers, arithmetic logic, and so forth.
The programmable interconnect and programmable logic are typically programmed by loading a stream of configuration data into internal configuration memory cells that define how the programmable elements are configured. The configuration data can be read from memory (e.g., from an external PROM) or written into the FPGA by an external device. The collective states of the individual memory cells then determine the function of the FPGA.
Another type of PLD is the Complex Programmable Logic Device (“CPLD”). A CPLD includes two or more “function blocks” connected together and to input/output (“I/O”) resources by an interconnect switch matrix. Each function block of the CPLD includes a two-level AND/OR structure similar to those used in Programmable Logic Arrays (“PLAs”) and Programmable Array Logic (“PAL”) devices. In CPLDs, configuration data is typically stored on-chip in non-volatile memory. In some CPLDs, configuration data is stored on-chip in non-volatile memory, then downloaded to volatile memory as part of an initial configuration (programming) sequence.
For all of these programmable logic devices (“PLDs”), the functionality of the device is controlled by data bits provided to the device for that purpose. The data bits can be stored in volatile memory (e.g., static memory cells, as in FPGAs and some CPLDs), in non-volatile memory (e.g., FLASH memory, as in some CPLDs), or in any other type of memory cell.
Conventionally, three configuration access ports were used for redundancy. With respect to three configuration access ports for programming configuration memory coupled to field programmable logic gates, only one of such ports was active at a time. As only one of such ports is capable of being active at a time in order avoid data corruption or conflicts, voting circuitry was implemented to select which port to use. However, implementation of voting circuitry, as well as having three or more configuration access ports, required a significant amount of overhead.
It should be appreciated that using redundant configuration access ports provides increased reliability to mitigate effects of single event upset (“SEU”) or multi-bit upset (“MBU”) events. As is known, an SEU or MBU is generally due to radiation from space, such as heavy ion particles or other radiation, causing state of circuitry, such as memory cells, to flip. Below atmosphere, upsets caused by neutron or alpha particles could result in SEU or MBU as well, although at a much lower rate. Accordingly, redundant modules are often employed, especially for high reliability applications as they may not tolerate application downtime. However, as devices become smaller with smaller lithographies, the likelihood of SEU or MBU events may increase, and thus redundant modules may become more prevalent in space as well as terrestrial applications.
As previously indicated, conventionally, a triple module redundancy with voting circuitry was used. Such triple module redundancy was to mitigate effects of SEU or MBU events, and generally involved partial reconfiguration through a configuration interface. By partial reconfiguration, it is generally meant that only a portion of a configuration, such as may be associated with a configuration bit stream, is reloaded or reprogrammed for a repair. Furthermore, such partial reconfiguration may be active or dynamic, meaning that operation of an FPGA is not ceased, and in some embodiments operation of a user instantiated design is not ceased, for such partial reconfiguration. Such conventional SEU or MBU mitigation may employ an external configuration interface, such as a Select Map or JTAG interface, or an internal configuration interface, such as an internal configuration access port (“ICAP”); all of these interfaces are available on FPGAs from Xilinx, Inc., of San Jose, Calif. However, such conventional approaches for detecting and correcting errors involved using a microprocessor or micro-sequencer core, such as a PicoBlaze™ core available from Xilinx, Inc., instantiated in field programmable logic gates of an FPGA for purposes of voting, as previously described. This involved significant overhead.
As is known, Virtex® FPGAs available from Xilinx have built-in detection and correction logic for detecting SEUs and MBUs. For MBUs, correction conventionally involves reloading a portion of a configuration bit stream, namely partial reconfiguration, to correct multiple bits. An SEU, namely in which only one bit is in error, may be corrected with such built-in detection and correction logic by resetting the individual bit.
A limitation of solutions heretofore was having a single point of failure. For example, both external and internal configuration access ports provide access to configuration logic; however, if memory cells in an I/O interface or routing of such interfaces are upset by an SEU or MBU, the ability to access configuration logic, and in particular configuration memory associated with such configuration logic, was precluded. In other words, there was a single point of failure for a selected interface. Even though Virtex® FPGAs available from Xilinx each provide two ICAPs, configuration commands are first sent through an active ICAP in order for an alternative ICAP to subsequently obtain control for writing and reading to configuration memory of configuration logic. Thus if an ICAP currently having control, namely the primary or default ICAP, is upset, the back-up ICAP was rendered useless. Accordingly, the mitigation of such upsets was prohibited by the single point of failure.